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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Abstract 
This document defines extension to the Pseudowire Emulation Edge-to- 
Edge (PWE3) control protocol RFC 4447 and PWE3 IANA allocations RFC 
4446 required for the setup of Time-Division Multiplexing (TDM) 


pseudowires in MPLS networks. 
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Les 


Introduction 


This document defines an extension to the PWE3 control protocol 
[RFC4447] and PWE3 IANA allocations [RFC4446] required for the setup 
of TDM pseudowires in MPLS networks. 


Structure-agnostic TDM pseudowires have been specified in [RFC4553], 
and structure-aware ones have been specified in [RFC5086] and 
[RFC5087]. 


[RFC4447] defines extensions to the Label Distribution Protocol (LDP) 
[RFC5036] that are required to exchange PW labels for PWs emulating 
various Layer 2 services (Ethernet, Frame Relay (FR), Asynchronous 
Transfer Mode (ATM), High-Level Data Link Control (HDLC), etc.). The 
setup of TDM PWs requires both interpretation of the existing 
information elements of these extensions and exchange of additional 
information. 


The setup of TDM PWs using L2TPv3 will be defined in a separate 
document. 


The status of attachment circuits of TDM PWs can be exchanged between 
the terminating Provider Edges (PEs) using the PW Status mechanism 
defined in [RFC4447] without any changes. However, usage of this 
mechanism is NOT RECOMMENDED for TDM PWs since the indication of the 
status of the TDM attachment circuits is carried in-band in the data 
plane. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


PW FEC for Setup of TDM PWs 


[RFC4447] uses the LDP Label Mapping message [RFC5036] for 
advertising the FEC-to-PW Label binding, and defines two types of PW 
Forwarding Equivalence Classes (FECS) that can be used for this 
purpose: 


1. PWId FEC (FEC 128). This FEC contains: 
a) PW type 
b) Control bit (indicates presence of the control word) 
c) Group ID 


d) PW ID 
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e) Interface parameters Sub-TLV 

2. Generalized PW FEC (FEC 129). This FEC contains only: 
a) PW type 
b) Control bit 


c) Attachment Group Identifier (AGI), Source Attachment Individual 
Identifier (SAII), and Target Attachment Individual Identifier 
(TAII) that replace the PW ID 


The Group ID and the Interface Parameters are contained in separate 
TLVs, called the PW Grouping TLV and the Interface Parameters TLV. 


Either of these types of PW FEC MAY be used for the setup of TDM PWs 
with the appropriate selection of PW types and interface parameters. 


The PW types for TDM PWs are allocated in [RFC4446] as follows: 


0x0011 Structure-agnostic El over Packet [RFC4553] 
0x0012 Structure-agnostic T1 (DS1) over Packet [RFC4553] 
0x0013 Structure-agnostic E3 over Packet [RFC4553] 
0x0014 Structure-agnostic T3 (DS3) over Packet [RFC4553] 
0x0015 CESoOPSN basic mode [RFC5086] 

0x0016 TDMoIP AAL1 mode [RFC5087] 

0x0017 CESoPSN TDM with CAS [RFC5086] 

0x0018 TDMoIP AAL2 mode [RFC5087] 


0000000 0 


The two endpoints MUST agree on the PW type, as both directions of 
the PW are required to be of the same type. 


The Control bit MUST always be set for TDM PWs since all TDM PW 
encapsulations always use a control word. 


PW type 0x0012 MUST also be used for the setup of structure-agnostic 
TDM PWs between a pair of Jl attachment circuits (see [RFC4805]). 
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3. Interface Parameters for TDM PWs 
3.1. Overview 


The interface parameters that are relevant for the setup of the TDM 
PWs are listed below. 


| Interface Parameter | Sub-TLV ID | Length | Description 

| CEP/TDM Payload Bytes | 0x04 | 4 |Section 3.2 | 
| -=-====--=======-===-=- |------------ |-------- |---==---="=-- | 
| CEP/TDM Bit-Rate | 0x07 | 6 [Section 3.3 | 
| ---==-=--=-=--=-=------ |------------ |--------|------------ | 
| Number of TDMoIP AAL1 | 0x0E | 4 [Section 3.4 | 
| Cells per Packet | | | | 
| TDMoIP AAL1 Mode | 0x10 | 4 [Section 3.5 | 
| ----------------------- |-==--------- |-------- |--------=-=-- | 
| TDMoIP AAL2 Options | 0x11 | 8 or |Section 3.6 | 
| | | larger | | 
| | see note | 
| Fragmentation | 0x09 | 4 [Section 3.7 | 
| Indicator | | | | 
P |------------ |-------- |------------- | 
| TDM Options | 0x0B | 4, 8, |Section 3.8 | 

| | 


If not explicitly indicated otherwise in the appropriate description, 
the value of the interface parameter is interpreted as an unsigned 
integer of the appropriate size (16 or 32 bits). 


Note: The length of basic TDMoIP AAL2 Options interface parameter is 
8 bytes, and when the optional Channel ID (CID) mapping bases field 
is used, there is one additional byte for each trunk transported. 
Thus, if 1 trunk is being supported, this message occupies 9 bytes. 
Since there can be no more than 248 CIDs in a given PW, this can 
never exceed 256 (this when each channel comes from a different 
trunk). 248 channels translates to less than 9 Els, and so, for this 
case, the length is 
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3 


3; 


Sai 


3% 


no more than 17 bytes. A single PE is not required to support more 
than 10 AAL2 PWs (i.e., up to 2480 individual channels, which is more 
than carried by a fully populated STM1). Thus, the memory required 
to store all the AAL2 mapping information is typically between 80 and 
170 bytes per PE. 


CEP/TDM Payload Bytes 


This parameter is used for the setup of all SAToP and CESoPSN PWs 
(i.e., PW types 0x0011, 0x0012, 0x0013, 0x0014, 0x0015, and 0x0017) 
and employs the following semantics: 


1. The two endpoints of a TDM PW MUST agree on the same value of this 
parameter for the PW to be set up successfully. 


2. Presence of this parameter in the PWId FEC or in the Interface 
Parameters Field TLV is OPTIONAL. If this parameter is omitted, 
default payload size defined for the corresponding service (see 
[RFC4553], [RFC5086]) MUST be assumed. 


3. For structure-agnostic emulation, any value consistent with the 
MTU of the underlying PSN MAY be specified. 


4. For CESoOPSN PWs: 


a) The specified value P MUST be an integer multiple of N, where N 
is the number of timeslots in the attachment circuit. 


b) For trunk-specific NxDSO with CAS: 
i) (P/N) MUST be an integer factor of the number of frames per 
corresponding trunk multiframe (i.e., 16 for an El trunk and 


24 for a T1 or J1 trunk). 


ii) The size of the signaling sub-structure is not accounted for 
in the specified value P. 


5. This parameter MUST NOT be used for the setup of TDMoIP PWs (i.e., 
PWs with PW types 0x0016 and 0x0018). 


CEP/TDM Bit-Rate (0x07) 
This interface parameter represents the bit-rate of the TDM service 


in multiples of the "basic" 64 Kbit/s rate. Its usage for all types 
of TDM PWs assumes the following semantics: 
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1. This interface parameter MAY be omitted if the attachment circuit 
bit-rate can be unambiguously derived from the PW type (i.e., for 
structure-agnostic emulation of El, E3, and T3 circuits). If this 
value is omitted for the structure-agnostic emulation of T1 PW 
type, the basic emulation mode MUST be assumed. 


2. If present, only the following values MUST be specified for 
structure-agnostic emulation (see [RFC4553]: 


a) Structure-agnostic El emulation - 32 
b) Structure-agnostic T1 emulation: 
i) MUST be set to 24 in the basic emulation mode 
ii) MUST be set to 25 for the "Octet-aligned T1" emulation mode 
c) Structure-agnostic E3 emulation - 535 
d) Structure-agnostic T3 emulation - 699 
3. For all kinds of structure-aware emulation, this parameter MUST be 
set to N, where N is the number of DSO channels in the 
corresponding attachment circuit. 
Note: The value 24 does not represent the actual bit-rate of the T1 
or J1 circuit (1,544 Mbit/s) in units of 64 kbit/s. The values 


mentioned above are used for convenience. 


Note: A 4-byte space is reserved for this parameter for compatibility 
with [RFC4842]. 


3.4. Number of TDMoIP AAL1 Cells per Packet 


This parameter MAY be present for TDMoIP AAL1 mode PWs (PW type 
0x0016) and specifies the number of 48-byte AAL1 PDUs per MPLS 
packet. Any values consistent with the MTU of the underlying PSN MAY 
be specified. If this parameter is not specified, it defaults to 1 
PDU per packet for low bit-rates (CEP/TDM Bit-Rate less than or equal 
to 32), and to 5 for high bit-rates (CEP/TDM Bit-Rate of 535 or 699). 
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3.5.  TDMoIP AAL1 Mode 


This parameter MAY be present for TDMoIP AAL1 mode PWs (PW type 
0x0016) and specifies the AAL1 mode. If this parameter is not 
present, the AAL1 mode defaults to "structured". When specified, the 
values have the following significance: 


0 - unstructured AAL1 
2 - structured AAL1 
3 - structured AAL1 with CAS 


The two endpoints MUST agree on the TDMoIP AAL1 mode. 
3.6. TDMoIP AAL2 Options 


This parameter MUST be present for TDMoIP AAL2 mode PWs (PW type 
0x0018) and has the following format: 


0 1 2 3 
012345678901234567890123456789021 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
0x11 | Length | v | ENCODING | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Maximum Duration | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
CID mapping bases | 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+— + —+— + 


The fields in this parameter are defined as follows: 


V defines the Voice Activity Detection (VAD) capabilities. Its 
values have the following significance: 


0O means that activity is only indicated by signaling. 

1 means that voice activity detection is employed. 

3 means this channel is always active. In particular, this 
channel may be used for timing recovery. 


Encoding specifies native signal processing performed on the payload. 
When no native signal processing is performed (i.e., G.711 encoding), 
this field MUST be zero. Other specific values that can be used in 
this field are beyond the scope of this specification, but the two 
directions MUST match for the PW setup to succeed. 
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Maximum Duration specifies the maximum time allowed for filling an 
AAL2 PDU, in units of 125 microseconds. For unencoded 64 kbps 
channels, this numerically equals the maximum number of bytes per PDU 
and MUST be less than 64. For other encoding parameters, larger 
values may be attained. 


CID mapping bases is an OPTIONAL parameter; its existence and length 
are determined by the length field. If the mapping of AAL2 CID 
values to a physical interface and time slot is statically 
configured, or if AAL2 switching [Q.2630.1] is employed, this 
parameter MUST NOT appear. When it is present, and the channels 
belong to N physical interfaces (i.e., N Els or Tls), it MUST be N 
bytes in length. Each byte represents a number to be subtracted from 
the CID to get the timeslot number for each physical interface. For 
example, if the CID mapping bases parameter consists of the bytes 20 
and 60, this signifies that timeslot 1 of trunk 1 corresponds to CID 
21, and timeslot 1 of trunk 2 is called 61. 


3.7. Fragmentation Indicator 


This interface parameter is specified in [RFC4446], and its usage is 
explained in [RFC4623]. It MUST be omitted in the FEC of all TDM PWs 
excluding trunk-specific NxDSO services with CAS using the CESoPSN 
encapsulation. In the case of these services, it MUST be present in 
the PW FEC if the payload size specified value P differs from 
Nx(number of frames per trunk multiframe). 


3.8. TDM Options 


This is a new interface parameter. Its Interface Parameter ID (0x0B) 
has been assigned by IANA, and its format is shown in Figure 1 below: 


0 1 2 3 
02 3-A 6 7.8 90 T 23A 5 6 T8 90 E 2 3A 67 8.9 0 1 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Parameter ID | Length |R|D|F|x|SP |cas| RsvD-1 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0 | PT | RSVD-2 | FREQ | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| SSRC | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 1. Format of the TDM Options Interface Parameter Sub-TLV 
The fields shown in this diagram are used as follows: 


Parameter ID Identifies the TDM PW Options interface 
parameter, 0x0B. 
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Length 4, 8, or 12 (see below). 


R The RTP Header Usage bit: if set, indicates that 
the PW endpoint distributing this FEC expects to 
receive RTP header in the encapsulation. RTP 
header will be used only if both endpoints expect 


to receive it. If this bit is cleared, Length 
MUST be set to 4; otherwise, it MUST be either 8 
or 12 (see below). If the peer PW endpoint 


cannot meet this requirement, the Label Mapping 
message containing the FEC in question MUST be 
rejected with the appropriate status code (see 
Section 4 below). 


D The Differential timestamping Mode bit: if set, 
indicates that the PW endpoint distributing this 
FEC expects the peer to use Differential 
timestamping mode in the packets sent to it. If 
the peer PW endpoint cannot meet this 
requirement, the Label Mapping message containing 
the FEC in question MUST be rejected with the 
appropriate status code (see Section 4 below). 


F, X Reserved for future extensions. MUST be cleared 
when distributed and MUST be ignored upon 
reception. 

SP Encodes support for the CESoPSN signaling packets 


(see [RFC5086]): 

o 00” for PWs that do not use signaling packets 

o '’01’ for CESOPSN PWs carrying TDM data packets 
and expecting Customer Edge (CE) application 
signaling packets in a separate PW 

o 10” for a PW carrying CE application 
signaling packets with the data packets ina 


separate PW 


o '11’ for CESOPSN PWs carrying TDM data and CE 
application signaling on the same PW 
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CAS MUST be cleared for all types of TDM PWs 
excluding trunk-specific NxDSO services with CAS. 
For these services, it encodes the trunk framing 
like the following: 


o '01’ - an El trunk 
o 710” - a T1/ESF trunk 
o SELA - a Tl SF trunk 
RSVD-1 and RSVD-2 Reserved bits, which MUST be set to 0 by the PW 
endpoint distributing this FEC and MUST be 
ignored by the receiver. 
PT Indicates the value of Payload Type in the RTP 
header expected by the PW endpoint distributing 


this FEC. A value of 0 means that the PT value 
check will not be used for detecting malformed 


packets. 

FREQ Frequency of timestamping clock in units of 8 
kHz. 

SSRC Indicates the value of the Synchronization source 


ID (SSRC ID) in the RTP header expected by the PW 
endpoint distributing this FEC. A value of 0 
means that the SSRC ID value check will not be 
used for detecting misconnections. 

Alternatively, Length can be set to 8 in this 
case. 


Notes: 
1. This interface parameter MAY be omitted in the following cases: 
a) SAToP PWs that do not use RTP header [RFC4553]. 


b) Basic CESOPSN NxDSO services without CE application signaling 
[RFC5086]. 


c) TDMoIP AAL1 mode 0 or 2 PWs that do not use RTP 


d) TDMoIP AAL2 PWs that do not relay CAS signaling and do not use 
RTP. 
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4. 


2. 


This interface parameter MUST be present in the following cases: 

a) All TDM PWs that use RTP headers. 

b) CESoOPSN PWs that carry basic NxDSO services and use CESOPSN 
Signaling packets to carry CE application signaling. This case 
is discussed in detail in Section 4 below. 

c) CESoPSN PWs that carry trunk-specific NxDSO services with CAS. 

d) TDMoIP AAL1 mode 1 PWs. 

e) TDMoIP AAL2 PWs that relay CAS signaling. 

If RTP header and possibly the Differential timestamping mode are 

used, the value of the Length field MUST be set to 8 or 12 in 

order to accommodate the Timestamping Clock Frequency and SSRC 
fields. 

Usage or non-usage of the RTP header MUST match for the two 


directions making up the TDM PW. However, it is possible to use 
the Differential timestamping mode in just one direction. 


Extending CESOPSN Basic NxDSO Services with CE Application Signaling 


[RFC5086] states that basic NxDSO services can be extended to carry 
CE application signaling (e.g., CAS) in special signaling packets 
carried in a separate PW. 


The following rules define the setup of matching pairs of CESoPSN PWs 
using the PW ID FEC and the extensions defined above: 


1. 


The two PWs MUST: 
a) Have the same PW type. 


b) Use the same setup method (i.e., either both use the PWId FEC, 
or both use the Generalized PW FEC). 


c) Have the same values of all the Interface Parameters listed in 
Section 3.1 above with the exception of the code point in the 
SP field of the TDM Options parameter: 


i) For the PW carrying TDM data packets, the SP bits MUST be 
set to ’01’. 


ii) For the PW carrying the signaling packets, the SP bits MUST 
set to ’10’. 
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2. If the PWId FEC has been used: 


a) The value of PW ID for the CESoPSN PW carrying TDM data packets 
MUST be even. 


b) The value of PW ID for the CESoOPSN PW carrying CE application 
signaling MUST be the next (odd) value after the (even) PW ID 
of the CESoPSN PW carrying TDM data packets. 


When using the Generalized PW FEC for the setup of the two PWs, no 
specific rules for matching the two FECs are defined. 
Implementation-specific mechanisms MAY be employed to verify the 
proper matching of the TDM data PW with its associated CE signaling 
PW. 


If one of the two associated PWs has been established and the other 
failed to be established, or for any reason fails after having been 
established, the established PW MUST be torn down. 

5. LDP Status Codes 
In addition to the status codes defined in Sections 5.1 and 7.2 of 
[RFC4447], the following status codes defined in [RFC4446] MUST be 
used to indicate the reason of failure to establish a TDM PW: 


1. Incompatible bit-rate: 


a) In the case of a mismatch of T1 encapsulation modes (basic vs. 
octet-aligned). 


b) In the case of a mismatch in the number of timeslots for NxDSO 
basic services or trunk-specific NxDSO services with CAS. 


2. CEP/TDM misconfiguration: 
a) In the case of a mismatch in the desired usage of RTP header. 


b) In the case of a mismatch of the desired Timestamping Clock 
Frequency. 


c) In the case of a mismatch of expected signaling packets 
behavior for basic CESoPSN NxDSO services extended to carry CE 


application signaling in separate signaling packets. 


d) In the case of trunk-specific NxDSO services with CAS if the 
framing types of the trunks are different. 
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e) In the case of TDMoIP AAL1 PWs with different AAL1 modes 
specified by the endpoints. 


3. The generic misconfiguration error MAY be used to indicate any 
setup failure not covered above. 


In cases 2a, 2b, 2c, and 2e above, the user MAY reconfigure the 
endpoints and attempt to set up the PW once again. 


In the case of 2d, the failure is fatal. 


Note that setting of the Control bit (see Section 2 above) to zero 
MUST result in an LDP status of "Illegal C-Bit". 


6. Using the PW Status TLV 


The TDM PW control word carries status indications for both 
attachment circuits (L and M fields) and the PSN (R field) indication 
(see [RFC4553], [RFC5086], and [RFC5087]). Similar functionality is 
available via use of the PW Status TLV (see Section 5.4.2 of 
[RFC4447]). If the latter mechanism is employed, the signaling PE 
sends its peer a PW Status TLV for this PW, setting the appropriate 
bits (see Section 3.5 of [RFC4446]): 


Pseudowire Not Forwarding 

Local Attachment Circuit (ingress) Receive Fault 
Local Attachment Circuit (egress) Transmit Fault 
Local PSN-facing PW (ingress) Receive Fault 
Local PSN-facing PW (egress) Transmit Fault 


o0000 


As long as the TDM PW interworking function is operational, usage of 
the Status TLV is NOT RECOMMENDED in order to avoid contention 
between status indications reported by the data and control plane. 
However, if the TDM PW interworking function (IWF) itself fails while 
the PWE3 control plane remains operational, a Status TLV with all of 
the above bits set SHOULD be sent. 


7. IANA Considerations 


Most of the IANA assignments required by this document are already 
listed in [RFC4446]. Additional assignments have been made for four 
Interface Parameter Sub-TLV types (see Section 3.1): 


TDM Options (0x0B) 

Number of TDMoIP AAL1 cells per packet (0x0E) 
TDMoIP AAL1 mode (0x10) 

TDMoIP AAL2 Options (0x11) 


G0 0-0 
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8. 


10. 


10. 


10 


Security Considerations 
This document does not have any additional impact on the security of 
PWs above that of basic LDP-based setup of PWs specified in 
[RFC4447]. 
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